Subject: APPN DLUR-4 AP draft document available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Fri, 13 May 94 11:52:11 EDT

The DLUR architecture document has been updated and is available by
anonymous FTP to ibmstandards.cary.ibm.com under the name of
aiw/dlur/dlur4.psbin - the file is a PostScript file, but treat it
as binary when you get it and print it.  There are also compressed
versions of the file (aiw/dlur/dlur4.zipbin and aiw/dlur/dlur4.exebin)
as well as a BookManager version (aiw/dlur/dlur4.bookbin).

The items added in DLUR-4 are:

** 1) clarified DLUR/S session awareness information

      Questions have been asked during implementation about the
      contents of CV X'0E' and CV X'23' included in the CV X'2A' on
      RSP(ACTLU) and SESSST as well as about the contents of CV X'31'
      on SESSST.  This item has been opened to clarify the contents of
      these session awareness messages.

      The architecture has been updated to include the following:

        a) CV X'0E' in CV X'2A' included with RSP(ACTLU) and SESSST
           will carry the original Network Services PLU name.

        b) CV X'23' in CV X'2A' included with RSP(ACTLU) and SESSST
           will carry the LFSID of the stage between the DLUR and
           the PU.

        c) CV X'31' included with SESSST will carry the original BIND
           image of the stage between the PLU and the DLUR.

** 2) clarified DLUR session pacing and window size processing

      A question was raised as to whether the DLUR should set the BIND's
      Adaptive Session-Level Pacing support indicator based on the
      SLU support of extended BIND or on the REX stage pacing parameter.
      In investigating this, additional questions were raised about
      setting window size values in the BIND and handling non-negotiable
      BINDs.  The following clarifications/corrections will be made:

         a) The DLUR will remember the REX stage pacing parameter and
            window size fields from the Assign LU Characteristics
            (X'30') control vector included in the GDS variable
            encapsulating the ACTLU.  These fields will be used in
            processing a BIND for adaptive session pacing and for
            window size setting.

         b) The DLUR will set the BIND's Adaptive Session-Level Pacing
            support indicator to the same value as the REX stage pacing
            parameter.

         c) The DLUR will put the REX stage pacing window size into the
            BIND only if the DLUR changed the BIND's ASP indicator
            from 1 (adaptive) to 0 (fixed), and if the BIND is
            negotiable, and if the BIND pacing window size is zero.

         d) The DLUR will restore the ASP indicator in the RSP(BIND) to
            the value saved from the BIND unless the SLU is locally
            attached and the RSP(BIND) does not indicate adaptive
            session pacing support, in which case the DLUR can leave
            the ASP indicator at 0 regardless of the remembered value.

         e) The DLUR will set the Adaptive Session-Level Pacing
            support indicator in the BIND and RSP(BIND) for
            non-negotiable BINDs as well as negotiable BINDs.

** 3) indicated CV X'3C' for DLUR as ENCP is not required when DLUR
      is NN

      Christine Martin of Data Connection Ltd. asked the following:

         In the multi-subnet case when the DLUR node is building a
         Found reply in response to a Locate with the OCR bit on, the
         specifications say that DLUR should set the following:
                    CV'3C = NNS(DLUR)
                    CV'3C = DLUR as ENCP
                    CV'3D = SLU
                    CV'40 = DLUS
         My question is, if DLUR is a network node, should DLUR still
         return the above specifying DLUR as both NNS(DLUR) and DLUR
         as ENCP? Or should the Found reply be the following?
                    CV'3C = NNS(DLUR) = DLUR
                    CV'3D = SLU
                    CV'40 = DLUS

      It turns out both are acceptable but the second is preferable
      since it saves space and follows the APPN elision rules.
      Therefore, the document has been changed to indicate that setting
      the DLUR as ENCP is not required if DLUR = NNS(DLUR).

** 4) revised definition of terms chapter

      The existing chapter was submitted for editorial review, which
      produced the new expanded chapter.

** 5) included SSCP-PU session activation TG & CP-SVR pipe race
      condition processing

      There are two situations which have been reported during testing,
      both of which have to do with receiving two ACTPUs for a
      DLUR-supported PU, one over a TG (requested in XID3 with ACTPU
      Suppression Indicator off) and one encapsulated in a CP-SVR pipe:

         a) One situation occurred with a configuration where the DLUR
            and the DLUS were adjacent.  The XID exchange between the
            two nodes resulted in an ACTPU from the DLUS over the TG
            since the ACTPU Suppression Indicator was off.  Later
            activation of the CP-SVR pipe between the two nodes
            resulted in a second ACTPU for the same PU.

            If this happens, the DLUR will accept the first ACTPU and
            reject the second.  The same rule is followed if the first
            ACTPU arrived over the pipe and the second over the TG.

            Since in this case the DLUS and the DLUR are adjacent,
            there ought to be a mechanism for the DLUR to give the DLUS
            enough information to prevent it from sending two ACTPUs,
            preferably sending the ACTPU over the pipe.

            The solution for this situation involves a new XID3 bit,
            a DLUR ACTPU Indicator.  If an adjacent DLUS received an
            XID3 from the DLUR with this new bit set as well as the
            ACTPU Suppression Indicator reset, then the DLUS will not
            transmit an ACTPU over the TG.  Regular pipe activation
            mechanisms will later cause an ACTPU to be sent over the
            pipe, and the race condition will be avoided.

            Use of the new bit by DLURs is optional; some
            implementations have logic to control the setting of the
            ACTPU Suppression Indicator and will not encounter this race
            condition.  Other implementations may always reset the ACTPU
            Suppression Indicator and should set the DLUR ACTPU
            Indicator to avoid the adjacent DLUS-DLUR ACTPU race
            condition.

         b) The other situation occurred with a configuration where
            the DLUR and the DLUS nodes are not adjacent.  An ACTPU
            race condition could occur with a DLUR node receiving ACTPU
            for a DLUR-supported PU over a TG (as a result of sending
            XID3 with ACTPU Suppression Indicator to an adjacent
            non-DLUS node capable of sending ACTPU) followed by the DLUR
            receiving ACTPU for the same PU over a CP-SVR pipe.  Also
            the ACTPU over the pipe could arrive before the ACTPU over
            the TG.

            Here, as in previously described ACTPU race conditions
            (section 6.2.3.2), the rule to follow is: first ACTPU
            received always wins, and subsequent ACTPUs received for
            the same PU are rejected while the initial SSCP-PU session
            remains active.

** 6) corrected DDDLU processing for DLUR/S

      Reviewers from Metaplex and Data Connection Ltd. have pointed out
      that figure 6-9 is missing the RSP(NMVT).  This will be added in,
      and the references to SDDLU (Self-Defining Dependent LU) will be
      corrected to DDDLU (Dynamic Definition of Dependent LUs).

** 7) clarified requirement that DLUR node's link station must be
      primary in connections to downstream PUs supported by DLUR BF

      Figure 6-1 indicates that the ODAI bit will always be set by
      the DLUR node to 0 in PIUs flowing on the SSCP-PU and SSCP-LU
      sessions to a downstream PU (stage 4 in the figure).

      This means the DLUR node which is providing BF support for the
      downstream PU must assume the primary link station role.

      It was requested that this be specifically stated in the document
      in the light of other ongoing architectural investigations into
      the use of the ODAI bit in dependent flows.

** 8) clarified DLUR processing of 2 byte RSP(ACTLU) RUs

      An APAR was received concerning short response RSP(ACTLU) formats.
      In investigating this APAR it was decided that the following will
      will be considered acceptable RSP(ACTLU) formats:

          -  2-byte response
          -  3-byte response
          -  3-byte response plus either or both of the defined control
             vectors (CV X'00', CV X'0C')

      The DLUR will always take any of these formats and convert them
      to a 3 byte RU with both CVs.

      What needed clarification in the DLUR document was how to convert
      a received 2 byte RU into a 3 byte RU before adding the CVs.
      The DLUR will remember the FM and TS profiles (which together make
      up ACTLU RU byte 2).  This information will be used when
      converting a 2 byte RSP(ACTLU) into a 3 byte RSP(ACTLU).

** 9) added DLC signalling information formats for Token-Ring,
      Ethernet, Frame Relay PVC, and SDLC non-switched

The item almost but not quite added in DLUR-4 is:

** a) network management chapter to include DLUR changes to SNMP
      management - not quite ready; instead of postponing publication of
      entire document, we'll figure out a method of separately
      publishing that chapter for AP review in the next week or so and
      and merging it into the main document for CP review

I'm requesting comments on these items to be received no later than
May 30.  If there is a consensus for approval at that time, I will
consider the document (and all related items which had previously
been granted AD status) to be at AP status as of May 31.

I am requesting AP status on the document in the form in which it
received AD status, i.e., without an internals chapter.  I am also
planning on requesting CP status for the document at AIW5, again in its
current form.  This document has been proven sufficient to produce
interoperable implementations; there are several DLUR products planning
on shipping in the next few months who have built their implementations
from the DLUR document.  We should be working to get the DLUR
architecture to CP status in the same timeframe, and the next step is
granting AP status.

Data Connection Limited has agreed to make its DLUR internal
specification available to any AIW member requesting it.  We and DCL
are working to make their specification available on the ibmstandards
FTP repository.  This specification is for information purposes only; it
is not an architecture submission and is therefore not subject to the
approval process.

I want to thank Christine Martin, Mike Evans, John Lazar, and Neil
Collins of Data Connection Ltd. for their contributions in submitting
DLUR internal specifications.  Questions they asked and suggestions they
made during the creation of these specifications led to improvements in
the architecture document.

I also want to thank Paul Wood, Derek Bolton, and Peter Haig of
Metaplex for assisting in reviewing the DCL DLUR internal specifications.
Constructive work was achieved in the area of the NOF interface, but
time pressure prevented review beyond that.  Even so, the user
interface has been improved, not an insignificant item given the
importance of improving APPN's ease of use.

I hope this just the first example of multivendor APPN activities in
the AIW.

Ed Tremblay

---

From: [email-masked] (Mike Evans)
Date: Mon, 16 May 1994 08:10:15 +0000

In "APPN DLUR-4 AP draft document available", Ed Tremblay writes
> architecture to CP status in the same timeframe, and the next step is

We agree.  Data Connection will begin shipping a new release of SNAP APPN
containing DLUR at the end of July 1994.  Our experience has shown it is
possible to create an interoperable implementation of DLUR entirely from the
existing specification.  In particular, the specification now includes all
clarifications and corrections we required during our development and testing
efforts.

On this basis, we support Ed's proposals for the specificaton to achieve AP
status (and CP status) in its current form.

We intend to make our internal specification available to AIW members on the
ibmstandards FTP server.  In the interim, if anyone requires a copy, please
send an email request to the address below, and I will mail a hard-copy of
the document.

We would like to thank Ed for his efforts in putting the specification
together, and his timely responses to all our questions.

Mike

-- 
==============================================================
Mike Evans                          Data Connection Limited
([email-masked])                 Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 17 May 1994 10:34:00 -0400

In message "APPN DLUR-4 AP draft document available", 

>is not an architecture submission and is therefore not subject to the

Northern Telecom is satisfied with the current state of the document as a
basis for implementation. Expediting the process by going to AP status now 
and CP status at AIW5 is acceptable to us.

-------------------------------------------------------------------------------
Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-2626